assets/src/less/products.less (1)

472-499: LGTM: Well-structured form layout implementation.

The shipping dimension options layout is well-organized with proper spacing and width calculations. The 23.3% width with 2% margin for form groups ensures proper alignment in the grid system.

Consider using CSS custom properties (variables) for the repeated values:

 .dokan-shipping-dimention-options {
   .dokan-form-group {
-    width: 23.3%;
+    width: var(--form-group-width, 23.3%);
-    margin-right: 2%;
+    margin-right: var(--form-group-margin, 2%);
   }
 }

includes/Assets.php (1)

1040-1063: Track refactoring of variation-related strings.

The variation-related strings are properly implemented, but there's a TODO comment indicating they should be moved to Dokan Pro Assets class.

Would you like me to create a GitHub issue to track the planned refactoring of these strings to the Dokan Pro Assets class?

includes/ProductForm/Init.php (1)

269-269: Address the TODO: Add support for creating tags

There's a TODO comment indicating that support for creating tags needs to be added. Implement this functionality to enhance the product tagging feature.

Would you like assistance in implementing support for creating tags, or should I open a GitHub issue to track this task?

Configuration used: CodeRabbit UI
Review profile: CHILL

templates/products/dokan-category-header-ui.php (1)

25-25: Consider using more specific escaping function

While wp_kses_post() is secure, consider using esc_html() if $required_symbol is meant to only contain plain text (like an asterisk *). If it's meant to contain HTML (like <span class="required">*</span>), then wp_kses_post() is appropriate.

-        <?php echo wp_kses_post( $required_symbol ?? '' ); ?>
+        <?php echo esc_html( $required_symbol ?? '' ); ?>

includes/Dashboard/Templates/Products.php (1)

373-375: Enhance nonce verification failure handling

When nonce verification fails, it's good practice to inform the user about the issue. Consider adding an error message or redirecting the user to an error page to improve the user experience.

Apply this diff to add an error message upon nonce verification failure:

if ( ! isset( $_POST['dokan_edit_product_nonce'] ) || ! wp_verify_nonce( sanitize_key( $_POST['dokan_edit_product_nonce'] ), 'dokan_edit_product' ) ) {
+   self::$errors[] = __( 'Security verification failed. Please try again.', 'dokan-lite' );
    return;
}

Configuration used: CodeRabbit UI
Review profile: CHILL

#!/bin/bash
# Check if minimum PHP version is specified in composer.json or readme
rg -i "require.*php.*[0-9]" composer.json README.md

#!/bin/bash
# Description: Verify that only authorized users can create new products.

# Test: Search for permission checks before product creation.
rg 'new WC_Product_Simple' -A 10 | rg 'current_user_can\('

includes/ProductForm/Factory.php (2)

188-188: Typo in documentation comment.

There's a misspelling in the docblock comment on line 188. The word "registerd" should be corrected to "registered."

Apply this diff to fix the typo:

-     * Returns registerd section with given section id.
+     * Returns registered section with given section id.

---

285-293: Improve exception handling in create_item method.

In the create_item method, exceptions are caught broadly, which might obscure specific errors during item creation. Additionally, the exception class is not fully qualified, which could cause issues if there's a local Exception class.

Consider specifying the global namespace for the Exception class and handling specific exceptions if applicable:

         try {
             return apply_filters( 'dokan_product_form_item_created', new $class_name( $id, $args ), $type );
-        } catch ( \Exception $e ) {
+        } catch ( \Exception $e ) {
             return new WP_Error(
                 'dokan_product_form_' . $type . '_class_creation',
                 $e->getMessage()
             );
         }

Configuration used: CodeRabbit UI
Review profile: CHILL

dokan-class.php (1)

17-17: Consider documenting the dashboard integration pattern

The addition of the dashboard manager and template directory constant suggests an architectural shift towards better separation of concerns. Consider:

1. Documenting the integration pattern between the dashboard manager and other components.
2. Adding usage examples in the developer documentation.
3. Creating migration guides if this changes existing template handling patterns.

Also applies to: 218-218

includes/Product/Hooks.php (1)

Line range hint 420-460: Add null check and optimize array operations.

The method needs some improvements for robustness and efficiency:

1. Add null check for vendor object
2. Simplify array operations

Consider this refactor:

 public function product_review_notification_recipients( $emails, $comment_id ) {
     $comment = get_comment( $comment_id );
     
     $product = wc_get_product( $comment->comment_post_ID );
     if ( ! $product ) {
         return $emails;
     }
     
-    // Facilitate unsetting below without knowing the keys.
-    $filtered_emails = array_flip( $emails );
-
     $vendor = dokan_get_vendor_by_product( $product->get_id() );
+    if ( ! $vendor ) {
+        return $emails;
+    }
     
-    if ( array_key_exists( $vendor->get_email(), $filtered_emails ) ) {
-        unset( $filtered_emails[ $vendor->get_email() ] );
-    }
+    $filtered_emails = array_diff( $emails, [ $vendor->get_email() ] );
     
-    // revert the array flip
-    $filtered_emails = array_flip( $filtered_emails );
-
     // get admin email
     $admin_email = get_option( 'admin_email' );
-    if ( ! in_array( $admin_email, $filtered_emails, true ) ) {
-        $filtered_emails[] = $admin_email;
-    }
+    $filtered_emails = array_unique( [...$filtered_emails, $admin_email] );
     
     return $filtered_emails;
 }

includes/Dashboard/Templates/Products.php (1)

205-208: Consider caching ProductFormFactory section instances

Multiple calls to ProductFormFactory::get_section() with the same section name could be optimized by caching the section instances. This would reduce unnecessary object creation and improve performance.

+private static $cached_sections = [];

 public static function load_download_virtual_template( $post, $post_id ) {
     $product = wc_get_product( $post_id );
     if ( ! $product ) {
         return;
     }

-    $section = ProductFormFactory::get_section( 'downloadable' );
+    if ( ! isset( self::$cached_sections['downloadable'] ) ) {
+        self::$cached_sections['downloadable'] = ProductFormFactory::get_section( 'downloadable' );
+    }
+    $section = self::$cached_sections['downloadable'];

Also applies to: 237-240, 273-276, 303-306

tests/pw/utils/interfaces.ts (1)

Line range hint 126-131: Remove duplicate description properties in interfaces.

Several interfaces have duplicate description properties which is redundant and may cause confusion:

• simple interface (lines 126 and 131)
• downloadable interface (lines 140 and 145)
• variable interface (lines 161 and 171)
• external interface (lines 182 and 185)
• vendorSubscription interface (lines 247 and 253)

Remove the duplicate properties to maintain clean and unambiguous interfaces. For each interface, keep only one description property.

interface simple {
    productType: string;
    productName: () => string;
    category: string;
    regularPrice: () => string;
    description: string;
    storeName: string;
    status: string;
    stockStatus: boolean;
    editProduct: string;
-   description: string;
    saveSuccessMessage: string;
}

interface downloadable {
    productType: string;
    productName: () => string;
    category: string;
    regularPrice: () => string;
    description: string;
    storeName: string;
    status: string;
    stockStatus: boolean;
    editProduct: string;
-   description: string;
    saveSuccessMessage: string;
    // ... rest of the interface
}

interface variable {
    productType: string;
    productName: () => string;
    category: string;
    regularPrice: () => string;
    description: string;
    storeName: string;
    status: string;
    stockStatus: boolean;
    attribute: string;
    attributeTerms: string[];
    variations: {
        linkAllVariation: string;
        variableRegularPrice: string;
    };
-   description: string;
    saveSuccessMessage: string;
}

interface external {
    productType: string;
    productName: () => string;
    productUrl: string;
    buttonText: string;
    category: string;
    regularPrice: () => string;
    description: string;
    storeName: string;
    status: string;
-   description: string;
    saveSuccessMessage: string;
}

interface vendorSubscription {
    productType: string;
    productName: () => string;
    category: string;
    regularPrice: () => string;
    description: string;
    numberOfProducts: string;
    packValidity: string;
    advertisementSlot: string;
    expireAfterDays: string;
    storeName: string;
-   description: string;
    status: string;
}

Also applies to: 140-145, 161-171, 182-185, 247-253

includes/functions.php (1)

702-716: LGTM! Consider adding ARIA attributes for accessibility

The addition of the description tooltip is well implemented with proper escaping. For better accessibility, consider adding ARIA attributes.

 <i
     class="fas fa-question-circle tips"
     aria-hidden="true"
+    role="tooltip"
+    aria-label="<?php echo esc_attr( $desc ); ?>"
     data-title="<?php echo esc_attr( $desc ); ?>">
 </i>

Configuration used: CodeRabbit UI
Review profile: CHILL

#!/bin/bash
# Description: Verify the existence and implementation of ProductForm\Init class

# Check if the Init class file exists
fd -e php "Init.php" includes/ProductForm

# Check the class implementation
ast-grep --pattern 'class Init {
  $$$
}'

# Look for any usage of this class
rg -l "ProductForm.Init" --type php

#!/bin/bash
# Get the implementation of Init class
cat includes/ProductForm/Init.php

#!/bin/bash
# Check for any other plugins hooking into the same actions with competing priorities
rg -A 2 "add_action\(\s*'dokan_render_product_edit_template'|add_action\(\s*'dokan_product_edit_after_title'|add_action\(\s*'dokan_product_edit_after_main'|add_action\(\s*'dokan_product_edit_after_inventory_variants'"

#!/bin/bash
# Check the implementation of template loading methods to understand the dependency order
ast-grep --pattern 'function load_product_edit_template($$$) { $$$ }'
ast-grep --pattern 'function load_download_virtual_template($$$) { $$$ }'
ast-grep --pattern 'function load_inventory_template($$$) { $$$ }'
ast-grep --pattern 'function load_downloadable_template($$$) { $$$ }'
ast-grep --pattern 'function load_others_template($$$) { $$$ }'

#!/bin/bash
# Search for the template loading methods implementations
rg -A 5 "public (static )?function (load_product_edit_template|load_download_virtual_template|load_inventory_template|load_downloadable_template|load_others_template)"

#!/bin/bash
# Search for template loading calls within these methods
rg -B 2 -A 10 "dokan_get_template(_part)?\(" includes/Dashboard/Templates/Products.php

src/admin/pages/Settings.vue (2)

52-54: Add prop validation for action button properties.

Consider adding prop validation to ensure action_button and action_button_label are properly defined in the section object.

 export default {
   // ...
+  props: {
+    section: {
+      type: Object,
+      required: true,
+      validator: function(obj) {
+        return typeof obj.action_button === 'string' && 
+               typeof obj.action_button_label === 'string';
+      }
+    }
+  },
   // ...
 }

---

71-71: Optimize prop passing to Fields component.

Passing the entire settingFields object could trigger unnecessary re-renders. Consider passing only the required subset of fields for the current section.

-:setting-fields='settingFields'
+:setting-fields='settingFields[index]'

src/admin/components/Fields.vue (1)

498-499: Add validation for custom field components.

The custom field components receive new props but lack validation. Consider adding prop validation in the component registration process.

Add validation when registering custom components through the getDokanCustomFieldComponents filter:

// Example validation in custom component registration
dokan.hooks.addFilter('getDokanCustomFieldComponents', 'dokan', function(components) {
  return components.map(component => {
    // Ensure component has prop validation
    if (!component.props) {
      component.props = {
        allSettingsValues: {
          type: Object,
          required: true
        },
        settingFields: {
          type: Object,
          required: true
        }
      };
    }
    return component;
  });
});

templates/products/edit/edit-product-single.php (1)

15-15: Avoid using global variables and disabling coding standards

Using global $post; and disabling WordPress.WP.GlobalVariablesOverride.Prohibited is discouraged. Refactor the code to pass the $post variable explicitly without relying on the global scope to enhance code clarity and maintainability.

Configuration used: CodeRabbit UI
Review profile: CHILL

-<a class="dokan-close" data-dismiss="alert">&times;</a>
+<button type="button" class="dokan-close" data-dismiss="alert">&times;</button>